The following sections identify the modifications to the allShare product since the release of allShare v1.1 in July of 1990.
v1.1.7 release notes (June 14, 1991):
Several clients have complained of OMNIS and Excel not remembering the locations of files when re-opening linked documents. This problem only ever occurred when allShare was running in Public Folder mode. The problem was with the creation of the full file path because allShare fakes the system into believing the public folder is a volume. This shouldn't be a problem anymore because we're now consistent in our fake-out.
v1.1.6 released (June 4, 1991):
Release 1.1.6 fixes inconsistencies not caught by Beta System 7 but that caused errors writing to the server under the released System 7 software.
v1.1.5 release notes (May 10, 1991):
The following changes were made to allShare to provide for System 7.0 compatibility:
1) Copying Folders to an allShare server from a System 7 client caused an error during the copy. This is the result of folder permission calls being made to establish default folder ownership. allShare 115 now deals with these access control values correctly.
2) some misc. speed improvements are included in this version, but most users won't notice any difference.
3) allShare DOES work on a System 7.0 Mac. In fact, since some programs don't agree with System 7's FileShare, we're using allShare on all our System 7 Macs! Remember to remove the FileShare extension from the Extensions folder. Also, note that allShare uses VERY little RAM in comparison to FileShare. Finally, allShare runs faster with System 7 than with System 6 under Multifinder.
4) allShare mounted volumes can be aliased for faster mounting.
v1.1.4 release notes:
The following minor problems have been resolved in this fix:
1) FileMaker Pro was using the wrong size parameter block for opening local files. This caused the program to either get address errors (and the bomb dialog) or to simply quit back to the finder. This error has only been reported on the older Macintosh Plus and SE.
2) Ready Set Go couldn’t open its own documents if they were placed at the root level on a hard-disk volume. This was the result of invalid parameters on input to the OpenDeny call when made locally.
Both of these problems don’t exist unless you’re accessing files locally. Across the network, all opens were operating correctly because the AppleShare Workstation software was properly correcting the parameters. No other programs should be affected by these modifications.
v1.1.3 release notes:
The following release of allShare represents only fixes to specific problems reported with allShare 1.1.2. The following changes have been made:
1) shutdown dialogs are now stored in the system heap for use instead of depending on the allShare file being available to open under low RAM conditions for shutdown. This makes the shutdown dialog available even when some of the system heap becomes corrupt. Also, this change should solve some problems when shutdown is chosen on an A/UX serving client (since A/UX pulls the rug out).
2) timeouts for writing packets to the server have been extended to compensate for gateways using slower transmission mediums (ie modem/router systems).
3) Works v2.0 and FileMaker Pro both attempt to open a file with exclusive access and then do the same call again to ensure that denyMode operations are available on this server. The second open is suppose to fail and it does but allShare wasn't placing the fileNumber into the reply packet correctly.
4) Local file open calls in some newer programs (among them Works 2.0 and FileMaker Pro) were executing an OpenDeny call locally using working directories — which allShare didn't process correctly and returned as an error. This could result in "could not be opened", "file is locked or busy" or "file not found" errors depending on the program. After receiving one of these errors, the user might not be able to unmount the volume or re-open the file (locally or over the network). Version 1.1.3 now handles these "interpretations" of the OpenDeny call correctly.
5) Volume lock and file lock errors were not being translated to the correct AFP error code so clients of an allShare server may have been getting improper error messages in these cases.
6) Under very unusual cases, allShare permitted two users exclusive Read/Write access to the file. This (obviously) meant that the file wasn't exclusive and caused record locking conflicts - AT NO TIME HAS THIS CAUSED DATA CORRUPTION. Our byte-range locking code compensated for the exclusive access the first time the second user tried to write to the file — albeit a little late.
v1.1.2 release notes:
- allShare can now publish A/UX v2.0 volumes on the network
- install instructions for A/UX users are specified below
- fixed problems on allShare installation (during a startup or restart) when the user didn't have AppleTalk active (using the chooser). This resulted in "Unknown Errors" during Finder copies and duplicates.
v1.1.1 release notes:
- fixes a problem with Finder copies that prevented the user from copying/duplicating locked files (locked checkbox in Get Info Dialog)
